Avant-propos

promo2016
Figure 1. La promo 2016/2017

Désolé…​

  • …​ pour l'anglais (really?)

  • …​ de ne pas être un spécialiste d’Android

  • …​ que vous soyez seulement la 2ème promo à subir ce cours

  • …​ que ce cours arrive avant que vous sachiez développer en Android/Mobile (majorité)

  • …​ que vous ayez à bosser sans ordi ce matin! (au moins 1h30!)

1. Content

  • Brainstorming & organization

  • Internet search & site web building

  • UML & Modeling for Mobile Applications

  • Case study

2. Organisation prévue

Module de 21h :

  • 4 créneaux semaine 41

    • [1] Intro & Brainstorming (10/10)

    • [2] Travail de groupe (10/10)

    • [3] Première maquette du site Web (11/10)

    • [4] UML rappel et concepts importants (11/10)

  • 10 créneaux semaine 41-42

    • [5] Gestion de projet spécifique, UML (13/10)

    • [6] Mise en oeuvre sur une étude de cas (13/10)

    • [7-8] Reverse ingéniérie d’une application Android (17/10)

    • [9-13] Modélisation : projet perso (binôme) (17-18/10)

    • [14] Présentation publique de votre appli perso (binôme) (19/10)

    • [14] QCM exam final (19/10)

3. Let’s start Brainstorming

whiteboard2015
Figure 2. Résultat 2015/2016
Background 2015/2016

Répartition des technos connues (depuis 2015) :

Répartition des technos connues (2015) :

Résultats du brainstorming 2016/2017 (merci Nathan Coustenoble pour la prise de note) :

Technos2016
Figure 3. Résultats 2016/2017

4. Wrap-up

Par petits groupes :

  • [1] Préparation du site web

  • [2] Liste des concepts UML connus et utiles

  • [3] Outils et langages de description d’écrans

  • [4] Plateformes de développement Android

  • [5] Différences iOS /Android

  • […​] Résultats du brainstorm

Les numéros ne représentent pas un ordre d’importance!

4.1. Plans B …​

  • Spécificités des applications mobiles

  • Modélisation des interfaces

  • Modélisation de l’architecture

  • Modélisation du comportement

  • Agilité et applications mobiles

4.2. [1] Site web des fiches

Je fait parti de ce groupe!

4.3. [2] Concepts UML connus

  • 1. Recensement des concepts connus

    • diagrammes

    • concepts dans ces diagrammes

    • méthodes (RUP, OpenUP, Agile)

    • ⇒ Google Sheet ?

  • 2. Pour le Mobile Modeling

    • brainstorming

4.4. [3] Outils et langages de description d’écrans

  • Type SNI (Schéma de Navigation des Interfaces)

  • Dessin / Générationd de code

  • Focus sur les Open Sources of course

  • …​

4.5. [4] Plateformes de développement Android

  • Avis objectifs (chiffrés)

  • Aspects historiques

  • Focus sur les Open Sources of course

  • …​

4.6. [5] Différences /

  • Niveau modélisation

  • Concepts

  • Cycle de développement

  • …​

4.7. Consignes

Pour chaque groupe (sauf [1]) :

  • Exprimer le problème

  • Rechercher les solutions existantes

  • Brainstormer sur la meilleure solution

  • La formaliser un minimum

  • Remplir un poster sous la forme d’une fiche (cf. point suivant)

  • Merger sa branche

4.8. Fiche

  • Titre

    • Motivations & problems (shortly)

    • Current approaches

    • Proposed approach

    • Example

4.9. Résultats

En 2015/2016 nous avons eu deux équipes chargées du site web :

Pour 2016/2017 nous avons eu deux équipes chargées du site web :

5. Exemple complet de démarche "ad hoc" autour d’UML

Nous allons aborder une étude de cas tirée du livre de Pascal Roques.

prfc

5.1. Le cahier des charges

Il s’agit de développer un service de vente en ligne (http://jeBouquine.com).

Depuis l’écriture du livre un vrai site de vente utilise cette URL!

5.2. Des besoins au code

(c) Pascal Roques
Figure 4. Le gap à combler (image tirée de [Roques2007a])

5.3. Raffinement des besoins

(c) Pascal Roques
Figure 5. Raffinement des besoins (image tirée de [Roques2007a])

5.4. Près du code

(c) Pascal Roques
Figure 6. Près du code (image tirée de [Roques2007a])

5.5. Comment trouver les classes ?

(c) Pascal Roques
Figure 7. Comment trouver les classes ? (image tirée de [Roques2007a])

5.6. Comment trouver les interactions ?

(c) Pascal Roques
Figure 8. Comment trouver les interactions ? (image tirée de [Roques2007a])

5.7. Liens entre diagrammes

(c) Pascal Roques
Figure 9. Liens entre diagrammes (image tirée de [Roques2007a])

5.8. Démarche complète

(c) Pascal Roques
Figure 10. Démarche complète (image tirée de [Roques2007a])

6. Diagrammatic models

6.1. UML Use Case Diagram

Exemple de Diagramme d'UC
Figure 11. Exemple de Diagramme d’UC

6.2. SysML Requirements Diagram

Exemple de Diagramme d'Exigence SysML
Figure 12. Exemple de Diagramme d’Exigence SysML

6.3. Sketch and drawings (Maquettes)

Dessin complexe
Figure 13. Un exemple de "mockup" réalisé avec l’outil balsamiq
L’IUT de Blagnac a une licence éducation qui vous permet d’utiliser <<<<<<< HEAD gratuitement {balsamiq} : {mybalsamiq}. ======= gratuitement Balsamiq : https://iutblagnac.mybalsamiq.com. >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963

6.4. UML Class Diagram

Exemple de Diagramme de classe
Figure 14. Exemple de Diagramme de classe

6.5. SNI: Schéma de Navigation d’Interface

Exemple de SNI
Figure 15. Exemple de SNI
<<<<<<< HEAD Il existe un plug-in eclipse pour SNI: http://sourceforge.net/projects/visual-sni/ ======= Il existe un plug-in Eclipse pour SNI: http://sourceforge.net/projects/visual-sni/ >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
Lien UC / SNI
Figure 16. Lien UC / SNI

6.6. UML State Machines

Diagramme d'états
Figure 17. Un Diagramme d’états

6.7. UML Sequence Diagram

Diagramme de Séquence
Figure 18. Un Diagramme de Séquence

6.8. UML Component Diagram

Diagramme de Composant
Figure 19. Un Diagramme de Composant

6.9. SysML Block Definition Diagram

Exemple de Diagramme de BDD SysML
Figure 20. Exemple de Diagramme de BDD SysML

6.10. SysML Internal Block Definition Diagram

Exemple de Diagramme d'IBD SysML
Figure 21. Exemple de Diagramme d’IBD SysML

6.11. UML deployment diagram

Deployement
Figure 22. Example of application deployment to Android (see [uml-diagrams])

7. Process examples

7.1. One example

  • 1) Identify the app users

  • 2) Identify the main functionalities

  • 3) Analyzing and expanding each functionality

7.2. Agile for Mobile Application Development

7.2.1. Example 1

Some restrictions with mobile application development are:

  • Mobile has restrictions: size of the apps, …​

  • Application should be downloadable very fast

  • Update applications quickly and smoothly

  • Error free and fast

  • Seamlessly interact with backend server as needed

7.2.2. Example 2

Challenges presented by developing mobile apps:

  • Short life cycles

  • Short development cycles

  • Limited hardware

  • Frequently changing user demands

  • Must be easily updateable

  • Must download quickly

7.2.3. Example 3

An “Agile with Discipline” approach for mobile app development

agile with discipline model
Figure 23. IBM approach for mobile app development (see [IBM])
Taken from [IBM]

7.2.4. Example 4

Multi-target User Interface design & Generation using MDE

Veldhuis
Figure 24. (Taken from [Veldhuis2013])]
Taken from [Veldhuis2013]

8. Reverse Engineering tools

<<<<<<< HEAD

8.1. Etude de cas : SLATShare

8.1.1. Cahier des charges

=======

9. Etude de cas : SLATShare

9.1. Cahier des charges

>>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963

SLAT

Le SLAT-Parapente est la section Parapente du club SLAT qui est lui-même le club montagne du CE d’Airbus.

Les membres de SLAT-Parapente organisent régulièrement des sorties pour co-voiturer et voler ensembles. Ils souhaitent que vous leur développiez une application pour gérer les frais liés à ces sorties. En effet, pour l’instant, chaque chauffeur remplit un fichier excel pour déclarer ses passagers, le kilométrage etc. Puis ensuite le trésorier de l’association fait des calculs d’apothicaire pour déterminer qui doit payer combien et à qui, en intégrant éventuellement la prise en charge du club sur les frais de déplacement.

ficheSortie
Figure 25. exemple de "Fiche Sortie" (un simple fichier excel)

En termes de données, une sortie peut être de différents types (vol, réunion, séjour, …​) et concerner un ou plusieurs chauffeurs. Les frais engagés sont :

  • les frais d’essence

  • les péages

  • éventuellement d’autres frais (nécessaire à la sortie)

Voici quelques caractéristiques et besoins clients (en vrac) :

  • <<<<<<< HEAD

    L’application à développer devra fonctionner sur des mobiles et tablettes {Android}.

    =======

    L’application à développer devra fonctionner sur des mobiles et tablettes Android .

    >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
  • On pourra différencier les rôles des personnes utilisant l’application (passager, conducteur, trésorier).

  • Même si un passager ne fait que l’aller, il participe aux frais A/R.

  • On pourra avoir un accès Web aux informations concernant les membres.

  • <<<<<<< HEAD =======

    Concernant les frais, chacun aura sur sa "page personnelle" les informations concernant le solde global en positif ou négatif et un récapitulatif de ses propres sorties.

  • >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963

    On pourra envisager toute option utiles pour le futur (comme le calcul du kilométrage à partir du GPS, l’ajout de passager par leur QR-Code, etc.).

  • <<<<<<< HEAD

    On pourra saisir les informations sur sa voiture (chevaux fiscaux, essence/diesel, consommatoin myenne, …​) .

Quelques commentaires :

    =======

    On pourra envisager également de coupler l’application avec la planification des sorties. Sur la base d’un calendrier, chacun peut se positionner présent un jour donné et tout le monde peux donc voir qui est présent ou disponible ce jour là. Peut-être même un système de vote associé à cette journée pour définir le lieux (modifiable afin de tenir compte de la dernière météo).

  • On pourra saisir les informations sur sa voiture (chevaux fiscaux, essence/diesel, consommatoin myenne, …​) . Quelques commentaires :

  • >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
  • Les passagers à l’aller ne sont pas nécessairement les mêmes qu’au retour.

  • Les prises en charge sont différentes selon le type de sortie (vol, réunion, séjour, …​)

  • "Chauffeur" veut dire "celui qui prend sa voiture" (ou plus précisément celui qui assume les frais). Bien évidemment, un chauffeur peut faire conduire un de ses passagers sans que cela change son statut pour l’application.

  • Le SLAT-Parapente possède également un mini-bus. Idéalement, l’application permettra de saisir un déplacement avec ce minibus (prise en charge parcitulière).

ficheSortieMinibus
Figure 26. La "Fiche Sortie" quand le minibus est utilisé

Vous pourrez vous inspirer d’applications comme :

exemple2

exemple1

exemple4

exemple5

<<<<<<< HEAD

8.1.2. Questions

=======

9.2. Questions

>>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
  1. Réalisez un diagramme des cas d’utilisation de cette application.

  2. Réalisez un diagramme de domaine (diagramme des classes métiers) de cette application.

    <<<<<<< HEAD =======
    dc2
    Figure 27. Exemple 2015/2016 (Ballades VTT)
    >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
  3. Quel type de diagramme utiliser pour représenter les écrans de votre application?

  4. Quel type de diagramme utiliser pour représenter des enchainements d’écrans ? Réalisez un diagramme de votre choix pour représenter les écrans principaux de votre application et leur enchaînement.

    <<<<<<< HEAD =======
    enchainement
    Figure 28. Exemple 2015/2016 (Ballades VTT)
    >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
<<<<<<< HEAD

8.1.3. Outils

=======

9.3. Outils

>>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
======= >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963

Vous pouvez accéder aux dessins de l’an dernier (https://iutblagnac.mybalsamiq.com/projects/voismabalade).

<<<<<<< HEAD

8.1.4. Résultats attendus

=======
  • Pour UML™ : Papyrus4Education, plantUML

  • 9.4. Résultats attendus

    >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963
    <<<<<<< HEAD

    8.1.5. Evaluation

    =======

    9.5. Evaluation

    >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963

    Rappelons les conseils habituels :

    • clarté des diagrammes et des choix (explicites) de conception ou d’interprétation réalisés

    • cohérence entre les diagrammes

    L’évaluation portera principalement sur les critères suivants :

    Table 1. Critères
    Critère Type de critère Poids approximatif

    Diagramme des UC

    Correction, pertinence

    15%

    Diagramme des Classes Domaine

    Correction, pertinence

    15%

    Maquettes utilisateur

    Correction, pertinence

    15%

    Diagramme d’un écran

    Correction, pertinence

    15%

    Cohérence inter-modèles (SNI/DSS, UC/DSS/DS/DCP)

    Correction, pertinence

    15%

    Communication/Présentations/Ignite

    subjectif :-)

    15%

    Clarté – Présentation du Dossier

    subjectif :-)

    10%

    Vous pouvez insérer une section "auto-évaluation" dans votre rapport, qui reprend cette grille et vous permet de vous auto-évaluer.

    <<<<<<< HEAD
    ======= >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963

    References and useful links

    References

    • [gram86] Ana Gram. Raisonner pour programmer. Dunod, 1986.

    • [HighsmithFowler2001] Jim Highsmith and Martin Fowler. The agile manifesto. Software Development Magazine, 9(8) :29–30, 2001.

    • [1030005] Kieran Conboy and Brian Fitzgerald. Toward a conceptual framework of agile methods : a study of agility in different disciplines. In WISER ’04 : Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research, pages 37–44, New York, NY, USA, 2004. ACM.

    • [Roques2007a] Les Cahiers du Programmeur, UML2, Pascal Roques 3ème Edition, Eyrolles, 2007.

    • [Roques2007b] UML 2 par la pratique, Pascal Roques 6ème Edition, Eyrolles, 2007.

    • [Blanc2006] UML pour les développeurs, Xavier Blanc, Eyrolles, 2006.

    • [Longepe2006] Le projet d’urbanisation du S.I., C. Longépé, 3ème édition, Dunod, 2006.

    • [Gillet2008] Management des SI, M. & P. Gillet, Dunod, 2008.

    • [Muller] Modélisation objet avec UML. {pam} & Nathalie Gaetner, Eyrolles, 2003.

    • [RUP] http://fr.wikipedia.org/wiki/Unified_Process

    • [AndroidFundamentals] http://developer.android.com/guide/components/fundamentals.html

    Glossary

    Ressources

    The following definitions are only informative. You can find usefull other sources here:

    ATL

    _ATLAS Transformation Language

    DRY

    Don’t Repeat Yourself

    EMF

    _Eclipse Modeling Framework

    IHM

    Interface Homme-Machine

    MCF

    Modèle Conceptuel des Flux

    MCT

    Modèle Conceptuel des Traitements

    MOA/MOE

    Maîtrise d’ouvrage (MOA) Maîtrise d’oeuvre (MOE)

    MOF

    Modèle Organisationnel des Flux

    MOT

    Modèle Organisationnel des Traitements

    OMG

    Object Management Group

    PPN

    Programme Pédagogique National

    SEF

    Schéma d'Enchaînement des Fenêtres

    SEP

    Schéma d'Enchaînement des Pages

    SI

    Système d'Information

    SNI

    Schéma de Navigation d'Interfaces

    SO

    Système Organisationnel

    SysML

    System Modeling Language

    TRL

    Technology Readiness Level

    URL

    Universal Ressource Locator

    About…​

    <<<<<<< HEAD

    Document made by Jean-Michel Bruel using Asciidoctor (version 1.5.4) from 'Dan Alen'. 'Licence Creative Commons'. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

    =======

    This web site has been developped by JMB using the following (open and free) tools:

    >>>>>>> 19e353f0dfc7f2f2a2d0839ed34325c9dc375963